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(54) Autokey initialization of cryptographic devices 



(57) In a cryptographic system, a device is manu- 
factured with a secure section that generates an internal 
secret. An irreversible cryptographic transform of the in- 
ternal secret is created and a certificate containing the 
irreversible cryptographic transform and a unique iden- 
tifier o1 the device is signed using a manufacturer key 
The device and the certificate are provided to a network 
operator. An initialization process is performed under 
the control of the operator to set up a secure channel 



between two devices under the control of the operator 
for secure communications between the two devices. 
Because of the internal secrets maintained within each 
device and the certificates, the devices can authenticate 
each other and communicate securely, even over an in- 
secure channel, without needing the devices to have 
been previously programmed with a secret of the oper- 
ator. The devices can authenticate each other and cre- 
ate a shared secret, all over an insecure channel. 
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Description 

[0001] The present invention relates to cryptograpliic systenns in general and to cryptographic systems that require 
secure initialization in particular. 

5 [0002] Cryptography is used to secure communications and data storage from unwanted access and tampering. 
Secure communications has several characteristics. One characteristic of secure communications is that a secured 
message cannot be read by an entity other than the message drafter and the message recipient. Another characteristic 
of secure communications is that an attacker cannot alter a message in transit from the drafter to the recipient without 
the recipient being able to detect that the message has been altered. Having a message altered in a detectable way 

10 is not so much of a concern, because the recipient can just discard the altered message as being an obvious forgery 
or a communication error. 

[0003] Of course, with most realizable secure communicatbns, a message could be rendered readable or alterable 
with enough time, effort and computing power. Notwithstanding such capability, a message is assumed to be unreadable 
or unalterable if an attacker could not read or alter the message without either having a decoding key for the message 

IS or expending more than a threshold amount of time or computing power "cracking" the message to read its contents 
or to create an altered message. Typically, secure communications systems are designed so that the threshold amount 
of time is greater than the length of time the message needs to remain secret and the threshold amount of computing 
power is much greater than the computing power available to any expected attacker at a cost commensurate with the 
benefit the attacker would obtain by cracking the message. 

20 [0004] In a more general description, a cryptographic system is a system that maintains one or more secrets used 
to limit the use of a communications or data storage system secured by that cryptographic system. Here, the term 
"communications system" is used to refer to any system that communicates data from a source to a destination, in- 
cluding those systems not traditionally thought of as communications systems, or transfers data to and from data 
storage in a secure manner (i.e., securing the "communications" from the data writer to the data reader). 

25 [0005] In securing one or more messages, the typical cryptographic system keeps those messages secret and is 
also used to ensure authentication, integrity and honrepudiatibn of messages. Of course, some cryptographic systems 
might not do alt of those functions. For example, one might set up a system where documents are authenticated but 
the authenticated documents are open for alt viewers to see. Authentication allows a recipient to verify that the purported 
sender of a message is the actual sender; integrity allows recipient to verify that the message recerved is exactly the 

30 message sent and non repudiation allows the recipient to prove to the sender, and others, that the message was actually 
serit by the sender. ' 

[0006] in some communications systertis designs, the cryptographic f unctrans are isolated in a cryptosystem module 
so that the serishive cryptographic operations can be closely controlled. The typical cryptosystem module maintains 
secrets that are used to encrypt, decrypt and verify messages. These secrets are often referred to as 'keys'. A key 
35 can be used to secure stored data, secure a communications channel, or other similar tasks. Securing data or a com- 
munications channel limits the use of the data or the channel to those persons or entities that know the key used to 
secure access!' 

[0007] Keys have several uses in securing a communications channel. One use is for encrypting and decrypting 
messages. In such a use, channel used to communicate from a source to a destination is assumed to be insecure in 

40 some way. An insecure channel might be subject to an "eavesdropping attack" where an attacker listens to traffic 
passing from the source to the destination. An insecure channel might also be subject to a "man-in-the-middle" attack 
where the attacker hot only, has the ability to listen into the traffic, but is also able to alter the message as it proceeds 
f rorri the source to the destination. An untrusted channel is a channel that might or might not be secure but that is 
assumed to be insecure. A security system that is designed for an untrusted channel assumes the channel is insecure 

45 in some way, but the security system will operate in the same fashion over a channel that turns out to be secure without 
the security measures added by the system design. 

[0008] ' These attacks can be made considerably nrK)re difficult by encrypting the traffic from the source to the desti- 
nation. With encryption, a plaintext message (i.e., a message readable by anyone in possession of the message) is 
converted to a ciphertext message using a key such that the ciphertext is not easily converted back to the plaintext 
50 message without knowing the key. Encryption is done using an encryptbn process with the plaintext message and a 
. key as inputs to the process. Preferably, the security of the message does not rely on the attacker being unaware of 
the details of the encryption process. In better cryptographic systems, it is assumed that the encryption process is 
entirely known and security is only provided by the key being unknown to the attacker 

[0009] The usefulness of each of the above facets of secure communicatbn can be illustrated with reference to a 
55 point-of-sale (POS) terminal network. POS terminials in a POS terminal network are used to facilitate a sale between 
a merchant and customer where the customer authorizes the customer's bank to transfer funds from the customer's 
bank account to the merchant's bank account to cover a sale. The transaction is effected through one or more messages 
between the merchant's POS terminal and other network devices. One goal of the POS terminal network is to secure 
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communications, so an eavesdropper or putative thief (generically referred to as an "attacker" in many cryptography 
texts) cannot read or undetectably modify the message traffic without knowing a message key. 
[001 0] As shoukf be apparent, the parties involved in a sales transaction want the message traffic to have the above 
aspects of secure communications. The customer wants to ensure that the communicatbn is secret, so that his or her 

s account number is not readable by an attacker. The bank wants to ensure that the communk^ations is authentic so that 
funds are only withdrawn, when duly authorized by the customer. The integrity of the messages needs to be ensured, 
so that an attacker cannot edit a message to replace the merchant's account number with the attacker's account 
number. Nonrepudiatbn is also important for the customer's bank because the bank does not want to be in a positk>n 
where they have paid the merchant for goods the customer took away from the point of sale but the customer repudiates 

10 the transaction and wants the transactbn to be backed out of his or her account. 

[0011] Each of these facets of secure communication can be assured if the bank and the customer take steps to 
secure communcatrans between the customer and the bank. Since the bank is more likely to be involved in setting up 
the infrastructure than the customer is, the customer's involvement in security is typically limited to selecting a password 
(a "key") and keeping the password secret. While the customer's task is a simple matter of memorizing a key, the 

IS bank's task is much more complex since there are many opportunities for an attacker to intercede in the communications 
to make it insecure. The risk is also much greater for the bank than the customer. If a customer's security is breached 
and an attacker obtains the customer's password, the attacker's take is usually limited to the funds available in that 
one customer's bank account. The take may be further limited if the customer notices the unauthorized activity in 
process. However, if the bank's security is compromised, the attackers take is not so limited and is not so noticeable. 

20 Because of this, the bank has great interest in having a secure system. 

[0012] If public key encryption is used, a pair of keys is generated with one of the keys being a private key and the 
other being a public key. In either case, a secure terminal contains secret keys. If an attacker is able to obtain those 
secret keys, the attacker may be able to listen in on message traffic to and from the secure terminal and may even be 
able to intercept the traffic. In some cases, the attacker knowing the secret keys might have enough knowledge to 

25 modify a message destined for the secure terminal and modify corresponding messages being sent by the secure 
terminal so that the attacker could continue to alter later message traffic without detection. Such a compromise could 
continue even after the secret keys were changed, if the attacker intercepts the messages containing a "change key' 
command and the new secret keys. . . 

[0013] Because of the continuing access, a compromised tenrhinal will remain a compromised terminal. Conversely. 

30 a secured terminal will usually be able to remain a secure terminal, if designed properly. Once a secure system is 
compromised, it cannot be considered a secure system. Therefore, the secure systern needs to be secure at every 
step o1 implementation, including the first Installation of the system. One difficulty with the first installatk>n is that the 
terminal needs to start with an initial set of' secret keys. The initial, set of secret keys can be changed remotely by 
sending the terminal a secured command message with the new. keys and instructions to change the keys. If the 

35 terminal is compromised before the "change keys" message is sent, then.it is possible that the attacker coukJ read the 
message and update its copy of the keys, thereby continuing' the compromise. In light.of the above vulnerabilities of 
cryptographs systems, the design of an initialization process for cryptographic devices must .be done carefully for the 
devices to be secure. , . 

[0014] One solution for device initialization that has been used is to iristall an initial set of keys during manufacture. 

40 A disadvantage of this solution is then the manufacturer would haye"to\eep track of the initial keys for each device 
and the purchaser of the terminal would have to rely on the manufacturer to keep that informatipn secure. If the initial 
keys are loaded in the clear, then anyone moriitoring the process pan capture.the keys and compromise the security 
of the device. Attematively, the manufacturer might produce the devices so that they all have a common initial key 
While the common initial key would allow for initial, unique, key loading secure from casual eavesdroppers, the security 

45 of a key common to many devices is doubtful. 

[0015] Another method of device initialization is the "trusted agent". approach., With. this approach, a cryptographic 
system is manufactured without keys and is initialized by a trusted agent of the owner of the cryptographic system by 
entering the key into the cryptographic system over a secure channel. If the cryptogriaphk; system is located on a 
remote networtc connected by insecure connections (such as the global Internet), then the trusted agent would have 

50 lo travel to the locatbn of the cryptographic system to enter the initialization key Typically, one employee of an agent 
is not enfirely trusted, so the initializatbn key will be dIvkJed among two trusted employees of the agent, who will each 
travel to the cryptographs system location to eriter their respective portions of the-initialization key This, of course, is 
expensive and time-consuming. Furlhemnore, if dedicated hardware, such as a key entry keyboard is used, it adds to 
the cost of the devrce and prevents automated key loading. ,. 

55 [0016] The trusted agent approach is currently used for bading the initial keys into new ATM's (automated teller 
machines) and PCS terminals (generically referred to herein as "terminals"). At least two security personnel who provide 
dual custody of DES key parts supervise the actual toading of keys from a key-loading device to the terminal. This key 
loading process is particularly burdensome in the case of debit POS terminals, as a typical network may have tens of 
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thousands of such terminals. 

[00171 To avoid travel to remote locations, a key depot could be used. A key depot is a secure location where all of 
the cryptographic systenns are brought after manufacture. At the key depot, initialization keys are loaded into crypto- 
graphic systems over secure channels and the cryptographic systems are then transported to where they will be used. 
This, in effect trades one expense tor another, albeit at some reduction of cost, since maintaining a physical key depot 
must be maintained and several extra transporting steps are needed, 

[00181 If^ a cryptographic system according to one embodiment of the present invention, a device is manufactured 
with a secure section that generates an internal secret. An irreversible cryptographic transform of the internal secret 
is created and a certificate containing the irreversible cryptographic transform and a unique identifier of the device is 
signed using a manufacturer key The device and the certificate are provided to a network operator. An initialization 
process is performed under the control of the operator to set up a secure channel between two devices under the 
control of the operator for secure communications between the two devices. Because of the internal secrets maintained 
within each device and the certificates, the devices can authenticate each other and communicate securely, even over 
an insecure channel, without needing the devices to have been previously prograrrimed with a secret of the operator 
The devices can authenticate each other and create a shared secret, all over an insecure channel. 
[00191 A further understanding of the nature and advantages of the inventions herein may be realized by reference 
to the remaining portions of the specification and the attached drawings. 
[00201 Fig. 1 is a block diagram of a network interconnecting secured devices. 

[0021] Fig. 2 is a block diagram of a secured device of Fig. 1 shown in greater detail, including a security module 
with a secure section. 

[00221 3 a block diagram bf the secure section of Fig. 2 shown in greater detail. 

[0023] Fig. 4 is a bkjck diagram of a manufacturing initialization facility illustrating a manufacturing initialization proc- 
ess for a device such at those shown in Fig. 1 -3. 

[0024] Fig. 5 is a flowchart of a process of autokey initialization, mutual authentication and shared secret generation 
as might occur between two devices connected over an untrusted channel. 

[0025] Fig. 6 is a block diagram of a key server as might be used with the network shown in Fig. 1 to initialize devices 
coupled to the network using the autokey process. 

[0026] The present invention has many applications, as will be apparent after reading this disclosure. In describing 
an embodiment of a security module according to the present invention, only a few of the possible variations are 
described. Furthermore, in this description, the specific application of a security module is used repeatedly as an 
example. Other applications and variations will be apparent to one of ordinary skill in the art. so the invention should 
not be construed as narrowly as the exainpleis; but rather in accordance with the appended claims. 
[0027] One specific application that is Used repeatedly in describing this system is the use of the security modules 
by a bank to control messages between the bank and its customers. The bank, being protective of its funds and cus- 
tomers, wants to ensure that funds transfer messages, and other communications, are confidential, authentic and 
intact. Being a strong guardian of its depositors' funds, the bank does not trust the manufacturer, the bank's customers, 
or the bank's employees not to eavesdrop on message traffic or intercede to modify the traffic to read confidential 
messages or to cause funds to be transferred from accounts the interceptor has no authority over. 
[0028] One example of a computer system that might be used by a bank or other securitynninded entity is system 
1 0 shown in Fig. 1 . In system 10. various devices are interconnected over a network 1 2. In this description, 'manufac- 
turer" is used to describe the entity that creates the device, or its agent or another entity with interests aligned with the 
manufacturer of the device. 'X)perator" is used to describe the entity that benefits from the use of the device or its 
agent, such as a purchaser of the device for installation in a secure network set up over networi< 12 by the operator to 
carry the operator's data. Nothing in the present invention requires that the manufacturer and operator be distinct 
entities, but it is assumed for security purposes that the operator's interests are such that the operator does not nec- 
essarily trust the manufacturer. * ; 

[0029] Network 12 is an untrusted network, but it should be understood that the present invention is not limited to 
use with an untrusted network.' One example of a network that might be used is the global internetwork of networks 
generally known as "the Internet". The Internet, almost by design, is insecure in that the routing of packets is generally 
uncontrolled and packets can be routed through many different computer systems unknown to, and uncontrolled by, 
either the sender or the "receiver. That routing allows an attacker with access to the routing components to both eaves- 
drop and nnodify data. 

- [0030] The devices shown in Fig. 1 being connected to network 12 include terminals 14 and a secure key and data 
manager (SKDM) 16, the operation of which is described in detail below For the purposes of illustration, an unauthor- 
ized terminal 14' and an unauthorized SKDM 16' are shown connected to network 12, Although such unauthorized 
equipment might be easily connected to network 12, as explained betow, the architecture and components of the 
authorized terminals 14 and SKDM 16 will prevent the unauthorized equipment 14', 16' from properly interoperating 
with the authorized equipment. 
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[0031] Fig. 2 shows one embodiment of temntnal 14 in greater detail. While Fig.. 2 is a block diagram o1 terminal 14, 
it should be understood that SKDM 16 could be constructed in a similar manner Terminal 14 is shown comprising an 
input/output (I/O) section 20, a terminal-specific logic block 22 and a security module (SM) 24. In a typk^l setup, the 
operator of the terminals purchases the terminals from the manufacturer and installs them onto network 12 for use by 

s the operator for some purpose specific to the operator. 

[0032] Security nxxJule 24 is shown comprising a secure section (SS) 26 and an unsecured section 28. A well- 
designed secure section has several properties common to well-designed secure sections, such as a tamper-resistant 
boundary. A tamper-resistant boundary makes is difficult for an attacker to get at ihe internal elements of the secure 
section without at least leaving clear evidence of a breach, such as a broken wire, an erased memory, or the like. 

10 Another property is that the secure section has tamper detection mechanisms to detect when penetratbn is in progress 
and erases or destroys secrets before the penetration is complete and the attacker obtains access to the secrets. 
Furtherrrwre, a well-designed secure section is togically secure, in that no set of signals, data inputs or commands 
exist that woukJ cause the secure section to release any of the secrets protected within the tamper-resistant boundary. 
[0033] Unsecured sectbn 28 contains logic and data that supports the operation of security nrxxJule 24 but that need 

15 not be kept secure, such as an I/O interface between SS 26 and the rest of terminal 14. Both secret and nonsecret 
data elements can be stored in SS 26, but il might be preferred to keep them separate so that any extra logic needed 
to secure a memory against reading need only secure the secret data elements. 

[0034] Fig. 3 is a block diagram of SS 26 in further detail. As shown there, SS 26 includes section I/O 30, process 
logic 32 (such as gates or a microprocessor), storage 34, a random number generator (RNG) 36 and an exponentiator 

20 38. The details of the data stored in storage 34 are described below in connection with various processes performed 
by SS 26. As is well-known in cryptographic system design, some security operations rely on random numbers and 
exponentiating values, so an attacker could defeat the security of a system by controlling or observing the random 
numbers generated by RNG 36 and the exponentiation performed by exponentiator 38. Therefore, a random number 
-generator (RNG) 36 and an exponentiator 38 are preferably secured within the tamper-resistant boundary of SS 26. 

25 [0035] The process of putting a terminal into operation will now be described. Since the initialization of terminal- 
specific logic block 22 depends on the specific use of the. terminal and that is outside the scope of this description, the 
focus is on the initialization of a secure section 26. The initializatbn of SS 26 is described here in two parts. The first 
part details the operations that are done by the manufacturer of SS 26, while the second part details the operatkxis 
that are done by or for the operator of SS 26. 

30 [0036] An SS manufacturing process is illustrated in Fig. 4. In the manufacturing environment 100 shown, a manu- 
facturing initialization facility (MIF) 110 comprises a manufacturing workstation (MWS) 112 that is part of MIF 110. MSW 
112 is coupled to a manufacturing installation security module (MISM) 114 that is secure within MIF 110. MIF 110 also 
includes a manufacturing database 116 that contains.data about security modules that have be initialized by MIF 110. 
[0037] A target SM 124 having a target SS 1 26 is shown coupled to MIF 110 via a link 1 20. In the process described 

35 below, target SM 124 is the SM being initialized. Link 120 need only be secure from data tampering, i.e., data sent 
from target SS 126 to MWS 112 is received by MWS 112 unaltered and data sent from MWS .112 to target SS 126 is 
received by target SS 126. Link 120 could also be secure from eavesdropping, but that is not necessary to maintain 
the overall integrity of the inilializatkxi of target SS 126. : ^- < ' . • 

[0038] Prior to the initialization process, target SS 126 can be generk:, i.e., iridividual target SS's 126 are identical. 

40 Target SS 126 becomes nongenerk; as a result of the initialization. process carried out by MIF 110. The details of one 
such initialization process are illustrated in the circled numbers in Fig. ,4 indrcating a set of ordered steps. Corresponding 
numbers are included in parentheses in the text below near, the steps that correspond to the circled numbers. 
[0039] To start, the MIF generates a serial number, SSID, for the target. SS and passes SSID to the target SS (step 
1). The target SS stores SSID (2) (in its storage 34; see Fig. 3) and generates a publk: key pair KSS (3) and stores 

45 the key pair in its storage 34. KSS comprises a private part KPVSS and a public part KPBSS. The generatbn of KSS 
can be triggered by the receipt of SSID., the receipt of a command from the MIF, or some other suitable trigger. Once 
the target SS generates KSS, it sends the public part (KPBSS) to the. MWS (4).- As part of the overall security of the 
system in which the target SS is installed, the private part KPVSS remains within the target SS and does not ever need 
to be communicated outside the target SS. 

50 [0040] The MSW provides KPBSS and SSID to the MISM, which generates a manufacturer certificate. MCert The 
manufacturer certificate contains KPBSS and is signed by an MIF private signature. key, KPVSIGM, maintained within 
the MISM (6). The MISM is initialized with the MIF signature key pair (KPVSIGM, KPBSIGM) before any SS's are 
initialized by the MIF The manufacturer certificate might also contain other data elements, such as SSID, the certificate 
version number, device permissions (for the target SS) and algorithm parameters (to be used by the target SS). the 

55 uses of which are described below. 

[0041] The manufacturer certificate is then passed from the MISM to the target SS for storage at in the target SS 
(7). along with the MIPs public signature key, KPBSIGM. whk;h is also stored within the target SS. The MIF also 
generates a veriftcation certificate 1 30 containing SSID and a copy of MCert (8). 
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[0042] At this point, the target SS is a duly manufactured device. It is nongeneric.-rn.that it has a specific identifier 
(SSID). but it is typically not specific to the eventual operator that will use the target SS. However, the target SS could 
be specific to an operator by using a different MIF signature key pair (KPVSIGM, KPBSIGM) for each operator Either 
way, the target SS preferably does not contain any operator secrets at this point. What follows is a description of an 

5 initialization process that configures a device to be specific to the networl^ that the;operator has set up. 

[0043] When the target SS is provided to the operator, that operator is provided with the verification certificate 130 
that goes with the target SS. The verification certificate need not be a secured certificate itself, but it is preferably 
provided under separate cover to the operator. The verification certificate allows the operator to verify that the target 
SS delivered under separate cover has a given unique identifier (SSID) and has been properly inifialized by the man- 

10 ufacturer. The operator can then install the target SS as an SS into an SM 24. Alternatively, the manufacturer could 
provide the SS already installed in an SM 24 or even provide the SS in an SM 24 already installed in tenminal 14 or 
SKDM16. 

[0044] Once the operator obtains the target SS. the operator connects it to network 1 2 (which is possibly insecure). 

The operator typically will run one or more SKDM's on network 12 and the first action taken with an SS is to k>ad 
15 operator secrets, such as key loading keys and key change keys, into the SS from the SKDM. One of the security 

concerns of the operator is that the SKDM not load keys into unauthorized terminal 14' and that an SS not accept 

commands and keys from an unauthorized SKDM 16'. Therefore, the SS and the SKDM should authenticate each 

other before transferring any operator secrets or data that could be used to compromise operator secrets. 

[0045] In the operator initialization (the second part of the initialization process), an SS and an SKDM (or two SS's 
20 for that matter) connect over an untrusted channel. Note that this process can be done with the devices connected 

over an insecure network in which data can be both obsen/ed and modified, and the process can be done without any 

prior installation of an operator secret in the device. 

[0046] One example of a specific mutual authentication process that might be used between two devices operated 
by the operator is shown in the flowchart of Fig. 5. Other variations o1 the process shown in Fig. 5 will be apparent to 

25 those of skill in the art from this description. The steps of the flowchart of Fig. 5 are numbered beginning with step S 
1 and those numbers are used in the text below, parenthetically. Generally, the steps are performed in the numbered 
order, but one of skill in the art will note from this description that the order of the steps can vary where a larger numbered 
one step does not require that a smaller numbered step be done before the larger numbered step. 
[0047] The process described in Fig. 5 authenticates two devices, device A and device B, to each other and results 

30 in a shared secret known only to device A and device B. Of course, with enough computing power or time, the shared 
secret could be obtained by an attacker, so the design of the system should be such that the annount of computing 
power or time is high enough to make an attack not worth the effort. One advantage of the process described below 
is that the generation of a shared secret is intertwined with the mutual authentication process. Another advantage of 
the process described below is that the mutual authentication process can be done without requiring a central certificate 

35 authority and a certificate chain between two devices. 

[0048] Device A could be terminal 14 or SKDM 16 (or more precisely, the SM 24 of one of those devices). Device B 
could also be terminal 14 or SKDM 16. For example, device A and B could be a terminal and an SKDM, respectively, 
or both devices could be terminals. 

[0049] The process begins with device A generating a key negotiation key (KNK) pair (KPVA1 . KPBA1) for authen- 

40 tication (step SI). Following the manufacturing process described above, device A contained several data elements, 
such as a unique idenfifier (labeled IDA in Fig. 5), an internal secret KPVA and a manufacturer certificate for device A 
(MCert;^)..Note that the intennal secret KPVA was created within the secure section of device A and never needed to 
be disctosed outside that secure section, even to the manufacturer. Device A creates two messages, Ml and M2, and 
sends those messages to device B. Message Ml contains IDA and KPBA1 , signed by KPVA. 

45 [0050] Once device B receives Ml and M2, device B verifies M2 using KPBSIGM, the manufacturer public signing 
key (S2). If M2 does not verify, device B stops the process and assumes that device A is an unauthorized device. 
Device B then extracts KPBA from M2 (S3). KPBA is the public part of the key of which KPVA is the private part. As 
explained above, that public part was included in the manufacturer certificate. At this point, device B is reasonably 
assured that KPBA is in fact the public part of the key, because the manufacturer certified it. 

so [0051] At step S4. device B verifies Ml using KPBA. If Ml does not verify, device B stops the process and assumes 
that device A is an unauthorized device. If Ml does verify, device B extracts KPBA1 from Ml (S5). At this point, device 
B has authenticated device A. The process of device A authenticating device B involves steps SB through S11 . It should 
be noted that steps SI through S5 need not happen in any particular order relative to steps S6 through S11 . However, 
If it is desirable to have M3 and M4 be secrets passed from device B to device A, device B can perform enough of the 

55 steps to generate the shared secret at least at device B. 

[0052] At step S6. device B generates its own key pair (KPVB1 , KPBB1 ) for authentication. As with device A, a duly 
manufactured device B also contains several data elements. Those data elements in device B include a unique identifier 
(labeled IDb in Fig. 5). an internal secret KPVB and a manufacturer certificate for device B (MCerte). The internal secret 
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KPVB was created within the secure section of device B and never needed to be disclosed outside that secure section. 
KPVB 1 is used in a later step to generate the shared secret. Device B creates two messages, M3 and M4, and sends 
those messages to device A (S7). Message M3 contains IDq and KPBB1 , signed by KPVB. Once device A receives 
M3 and ^W, device A verifies-M4. using KPBSIGM. the manufacturer public signing key (S8). If M4 does not verify, 

5 device A stops the process and assumes that device B is an unauthorized device. Device A then extracts KPBB from 
M4 (S9). KPBB is the' public part of the key of which KPVB is the private part, which is included in MCer%. At this point, 
device A is reasonably assured that KPBB is in fact the public part of the key, because the manufacturer certified it. 
[0053] At step SIC, device A verifies M3 using KPBB. If M3 does not verify, device A stops the process and assumes 
that device B is an unauthorized device. If M3 does verify, device A extracts KPBBl from M3 (S11 ). At this point, device 

10 A has authenticated device B and device B has authenticated device A. Furthermore, at this point, device A onlains 
KPVA1 andKPBB! and device B contains KPVB1 and KPBA1. With each of these two values, each device can generate 
the shared secret. Once each device generates the shared secret, the two devices can communicate between them- 
selves securely, by using the shared secret (SI 2A, SI 2B). One method of generating such a shared secret is described 
below, but other methods could be used to generate the shared secret. In some systems, it may be preferred to generate 

IS a shared secret that does not rely on the security of KPBSIGM, so that the operator's system is not compromised after 
■ a compromise of KPBSIGM. 

[0054] One method of generating a shared secret is a Diffee-Hellman (OH) exchange. A DH exchange uses two 
variables, a and n, that nr\ay or may not be secret and where a < n. Device A generates its key pair such that KPBA1 
= a^PVAi pTKxl n and device B generates its key pair such that KPBBl = a'^PVBi mod a Once device A extracts KPBBl 

20 from M3, device A can calculate = KPSBI'^p^^^ mod nand once device B extracts KPBA1 from Ml, device B can 
calculate Yq = KPBA1*^vBi „ However, because of the way those values were generated: 

YA-KPBBl*^^'^*modrt 

= KPBAl*^^^modn . 

,"Xb ■ . 

and therefore, since Y^^ = Y^, and performing discrete togarithms is difficult, devices A and B have a shared secret. In 
35 a particular embodiment, n is a large prime number (on the order. of 1024 bits) and a is. an element of a finite fieki 
having 2*» elements where q is a 160-bit prime that divides ^y^ and a. If Y = Y^^ = Y^ is one the order of 1024 bits, 
several keys can be created from Y, such as 56-bil DES keys. There are many different uses for the shared secret 
once it is created. 

[0055] Fig. 3 shows some details of the data values stored in storage 34: In a more detailed implementation, storage 
40 34 contains storage for the elements shown in Table 1 . . . 



TABLE 1. 





Element 


Description • 


45 


Version Number 


The version of the protocol used by the terminal to set up secure channels and/or exchange 
keys. , - . 




SSID 


A manufacturer assigned value unique to a specific terminal/target SS. 


SO 


Permissions Flags 


Flags indicating which actions are allowed. 




Key Loading Type 


The type of key loading that occurs in the initial autokey loading process. Examples: key 
exchange key, temporary superkey, terrhinal key loading key. 


SS 


KSS 


Key pair for the terminal (KPVSS, KPBSS). 




KPBSIGM 


Public portion of manufacturer's signature key. 



25 



30 
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TABLE 1 . (continued) 



Element 


Description 


MCert 
CD 


Manulacturer Certificate: a signature of KSS using the nnanufacturer key specific to the 
operator of the target SS. The data signed includes the Version Number, SSID, Permission 
Flags and KSS. 

Check Digits. 



[0056] If the permiss'lons flags are included in MCert. then a terminal cannot change its permissions once they are 
assigned by the MIR.The permissions flags might be set by the manufacturer to limit the functions that can be performed 
by the terminal as requested by the operator. The permissions flags might, for example, indicate: 



a. if MFKs can be shared among multiple security modules 

b. If the terminal is allowed to load other MFKs 

c. Load terminals with applicatbn programs. 

d. If the terminal is allowed to load key exchange keys (KEKs). 

e. If the terminal is allowed to load specific terminal keys. 

f . If DSA signatures are to be verified. 

[0057] The specific purpose of a terminal 14 is not the main aspect of this disclosure, but terminal 14 might be a 
point-of-sale (POS) terminal used to gather purchaser information or effect an electronic transaction, an automatic 
teller machine ("ATM'), a smart card reader or the like. In some cases, terminal 14 might be manufactured without 
security module 24 for some specific purpose and the security nrKxJule, manufactured by the terminal manufacturer or 
a separate security module manufacturer, added later. For example, an ATM can be manufactured with togic specific 
to an ATM, but without a security module. A security module that is not specific to an ATM can then be added to the ATM. 
[0058] In another example, the terminals are personal computers and the security modules are PCI bus cards in- 
stalled in the personal computers. Where the personal computers and security modules are manufactured by one 
company, the personal computers can be shipped with the security modules p reinstalled. Because of the initialization 
done at manufacture, the personal computers do not have to be manufactured specific to an operator, which simplifies 
the process of providing the personal computers to operators. 

[0059] A large organization might use tens of thousands of personal computers, all of which require a security module 
installed therein so that the personal computers can intercommunicate securely over an insecure network. Without 
security modules as described above, the organization would either need to have the security modules specifically 
preconfigured specifically for the organization including secrets of the organizatbn. such as master file keys, or the 
organization would need to have an infrastructure for securely transporting those organization secrets to the point of 
installation of the personal computers. However, with the above-described security nrxxJules, the organization can 
centrally manage its own keys and distribute them over an untrusted channel, preferably in a manner transparent to 
the end user of the personal computer within the organization. The end user might need only to run an initialization 
routine, which vyould then activate the security nrwdule to perform the mutual authentication process described in Fig. 
5 and then obtain keys for operation from a key server. 

[0060] Fig. 6 illustrates a key server 1 50 as might be connected to an untrusted network to load keys into a generic 
device to make the device specific to an operator. In one implementatbn, key sender 150 is a Windows NT server in 
a secure physical environment. Key server 150 is shown comprising server software 152. a terminal database 154, an 
audit tog 156 and network I/O 158. Network I/O 158 connects key server 150 to untrusted network 12 we well as 
connecting key server 150 to a security control terminal (SCT) 160 over a secured connection. As shown, SCT 160 
has an interface to a user via secured I/O 1 62. 

[0061] Terminal database 154 maintains a list of the serial numbers (SSID's) for each secure section used by the 
operator, as well as the MCerts for each of the secure sectbns. As the operator brings more terminals on line, the 
operator can add the SSID and MCert for each new terminal into terminal database 154. 

[0062] Cryptographic operatbns within key server 150 are performed by the security module 24* within key server 
1 50. More than one security module 24' might be used within key server 1 50, if that key sen/er is managing more than 
one subnetwork. Security module 24' can be the same as security module 24 described above, but for some key 
senders, the autokeying capability is not needed. Instead, the initial keys for the key server are loaded manually over 
a secure connection. One such secure connection is that provided by SCT 160, which is able to toad master file keys 
(MFK's) and read data from the secure section in a secure manner. 
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[0063] In the manner described above, a terminal and a key server, or two terminals, can connect securely over an 
insecure channel, where neither data integrity nor data confidentiality is assured, and securely pass messages and 
verify the authority of the other party to a conversatbn. This albws two terminals lo communicate messages between 
themselves, set up shared secrets, or to coordinate secure toading of keys over the insecure channel. For example, 
once the process shown in Fig. 5 is complete, the key server can securefy transmit a new set of keys or a 'key change' 
command to an SS and that SS can verify that the key server is what it claims lo be before changing keys. 
[0064] To prevent someone from undetectably inserting an unauthorized device into a network and having it verified 
by a key server, the key sender maintains audit log 156 of the terminals with which the key server has performed. A 
record in audit tog 1 56 contains the manufacturer-generated ID for the terminal (SSID) and a sequential record number. 
The sequential record numbers make deletions of records from audit tog 156 apparent. The records can be signed to 
prevent alteration. 

[0065] A system for loading an initial set of one or more keys without needing a secure channel to toad the initial set 
of keys has now been described. With this system, secure sections can be securely initialized and authenticated over 
insecure networks. 

[0066] The above description is illustrative and not restrictive. Many variations of the invention wilt become apparent 
to those of skill in the art upon review of this disclosure: The scope of the invention should, therefore, be determined 
not with reference to the*above description, but instead should be determined with reference to the appended claims 
along with their full scope of equivalents. 



Claims 

1 . A method of manufacturing a device for use by an operator for communicating with other devices operated for the 
operator, wherein a manufacturer has a noanufacturer key that is normally unavailable to others besides the man- 
ufacturer and its authorized agents and the communication is over an untrusted channel that is not assumed to 
be secure from eavesdropping or message mpdification, the method comprising the steps of: 

manufacturing the device to include a secure section such that the secure section need not contain a secret 
of the operator, the secure section being circuitry that is enclosed within a tamper-resistant boundary; 
initializing the device with a device identifier unique to that device; 
triggering the secure section to generate ah internal secret; 

creating, within the secure section, an irreversible cryptographic transform of the internal secret; 
outputting. from the device, the irreversible cryptographic transform as a public part of the internal secret; and 
generating a digital signature of the public part and the device identifier using the manufacturer key. 

2. The method of claim 1 , wherein each devtoe is manufactured as a generic device not specific to a particular operator 
or network onto which the device may be connected. 

3. The method of claim 1 , further comprising a step of certifying the device as being a properly manufactured device. 

4. The method of claim 1 , wherein the step of creating the irreversible cryptographic transform comprises a step of 
generating a public key pair where the public part of the iritemal secret is a public key port ton of the public key pair 

5. Using a device having an internal secret for which a digital signature of a public part of the internal secret and a 
unique device identifier using the manufacturer key exists, a method of setting up 'a secure channel between the 
device and a key server over an untrusted channel, the method comprising the steps of: 

authenticating the key server to the devbe; 

authenticating the device to the key sen/er by requiring the device to provide a response to a challenge where 
the response is such that only a device knowing the internal secret could feasibly generate the response; 
creating a shared secret shared by the key sen/er and the device using information provided by the key server 
and the device in the steps of authenticating; and . 
using the shared secret for secure cornmunications over the channel. 

6. The method of claim 5. wherein the step of using the shared secret comprises at least one of transferring data 
between the key server and the device, transferring a key between the key server and the devtoe, setting a con- 
figuration value in the device, or reading configuratton values from the device. 
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7. A method of loading a key into a target device fronn a key server over an untrusted channel between the target 
device, and the key server, wherein the initial contents of the target device are assumed to be determinable by an 
untrusted entity, the method comprising the steps of: 

5 generating, within a secure circuit of the target device, a sessbn key that is a function of at least one variable 

whose value cannot be determined in advance of the step of generating; 
using the session key in configuring a secured channel over the untrusted channel; and 
loading at least one key from the key server to the target devfce using the secured channel. 

10 8. The method of claim 7, wherein the target device is a newly manufactured terminal to be added to a secure network 
and the target device is assumed to contain no secrets. 

9. A secure key loading system for securely loading keys from a key server to a target device over an untrusted 
channel, the secure key toading system comprising: 



15 



a secure chip within target device, the secure chip comprising: 



(a) a random number generator, 

(b) an exponent iator; and 

20 (c) togic to generate a secret session key from an output of the random number generator and the expo- 

nentiator such that the secret session key cannot be easily generated from knowledge of the logic and its 
manufactured state; and 

key server logic, within the key server, for decoding messages received by the target device encoded with the 
25 secret session key and for using the decoded messages to initiate a secure channel over the untrusted channel. 

1 0. A method of initializing a security device with an initialization key over an untrusted channel, comprising the steps of: 

generating a secret within a secured section of the security device constructed from hardware which is not 
30 known to be secret; and 

using the generated secret to communicate securely between the security device and an external node. 

11. The method of claim 10, where the external node is a node associated with a key server, the method further 
comprising a step of loading at least one key into the security device from the key server using a secure commu- 

35 nications channel established using the generated secret key. 



40 



55 



10 



EP 1 081 891 A2 



10 







SECURE KEY 




AND DATA 




MANAGER 




(SKDM) 










■14 



TERMINAL 



14 



NETWORK 



TERMINAL 



14 



TERMINAL 



^16' 

f 

UNAUTHORIZED 
SKDM 



-14' 



UNAUTHORIZED 
TERMINAL 



F/G. 1. 



11 



EP 1 081 891 A2 



14 



^ 

TERMINAL-SPECIFIC 
FUNCTIONALITY 



I/O 



r 



20 



SECURITY MODULE (SM) 


^26 




SECURE 






SECTION (SS) 




^28 




UNSECURED 






SECTION 









F/G. 2. 



30 



I/O 



32 



PROCESS LOGIC 



r 



36 



RANDOM NUMBER 
GENERATOR 



11. 



38 



EXPONENTIATOR 



34 



STORAGE 




SSID 






KPVSS 






KPBSS 






MCERT 






KPBSIGM 













F/G. 3. 

12 



EP 1 081 891 A2 




13 



EP 1 081 891 A2 



DEVICE A CHANNEL 



DEVICE B 



( START ) 



S1 



GENERATE A KEY 
NEGOTIATION KEY 
(KNK)PAIRFORA 
= (KPVA1,KPBA1) 



AUTHENTI- 
CATION OF 
DEVICE B 




I 

m1=Sign^JID^.KPBA1] 
m2=MCert for Device A 



m3=sign^[IDB,KPBB 
m4=MCert for Device B 

_£ 



VERIFY m4 

USING 
KPBSIGM 



^88 
FAIL 



STOP ^ 



EXTRACT 
KPBB FROM 4 



-S9 



S10 



VERIFY m3 IFAIL 
USING KPBB 



( STOP ) 



EXTRACT 
KPBB1 FROM 
m3 



^S11 



-S12A 



GENERATE THE 
SHARED SECRET 
FR0MKPBB1 
ANDKPVA1 



S6 



GENERATE KEY 
NEGOTIATION 
KEY (KNK) PAIR 

FOR 
B=(KPVB1.KPBB1) 

^ 



S7 



SEND RESPONSE 



S2 



VERIFY m2 

USING 
KPBSIGM 



FAIL 

r 



EXTRACT 
KPBAFROM 
m2 



( STOP ) 
■S3 



VERIFY m1 
USING KPBA 



84 



FAIL 



EXTRACT 
KPBA1 FROM 
. m1 



-85 



AUTHENTI- 
CATION OF 
DEVICE A 



S12B 



GENERATE THE SHARED 
SECRET FROM KPBA1 AND 
KPVB1 



F/G. 5. 



14 



EP 1 081 891 A2 



KEY SERVER 



24" 



SECURIP*' 
MODULE 



152 



SERVER 
SOFTWARE 



158 



NETWORK I/O 



150 



•154 



TERMINAL 
DATABASE 



156 



AUDIT 
LOG 



r 



160 



SCT 



162 



SECURE I/O 




F/G. 6. 



15 



liiiiiiiiiiiiiiiiiiiiiniiiii 

(11) ' EP 1 081 891 A3 

(12) EUROPEAN PATENT APPLICATION 

(88) Date of publication A3: (51 ) int 0\7: H04L 9/32 

22.05.2002 Bulletin 2002/21 

(43) Date of publication A2: 

07.03.2001 Bulletin 2001/10 

(21) Application number: 00307223.8 



(22) Date of filing: 22.08.2000 



(84) Designated Contracting States: 


. » McKay, Michael 


AT BE CH CY DE DK ES Fl FR GB GR IE IT LI LU 


Benlomond, California (US) 


MCNLPTSE 


« Langford, Susan 


Designated Extension States: 


No. 101 Sunnyvale, California (US) 


AL LT LV MK RO SI 


• Hines, Larry 




No. 105 Santa Clara, California (US) 


(30) Priority: 02.09.1999 US 389157 






(74) Representative: Brunner, Michael John 


(71) Applicant: Compaq Computer Corporation 


GILL JENNINGS & EVERY, 


Houston Texas 77070 (US) 


Broadgate House, 




7 Eldon Street 


(72) Inventors: 


London EC2M 7LH (GB) 


o Hopkins, Dale Webster 




Gilroy, California 95020 (US) 





(54) Autokey initialization of cryptographic devices 




Europaisches Patentamt 
European Patent Office 
Office europeen des brevets 



(57) In a cryptographic system, a device is manu- 
factured with a secure section that generates an internal 
secret. An irreversible cryptographic transfomi of the in- 
ternal secret is created and a certificate containing the 
irreversible cryptographic transform and a unique iden- 
tifier of the device is signed using a manufacturer key. 
The device and the certificate are provided to a network 
operator An initialization process is performed under 
the control of the operator to set up a secure channel 



between two devices under the control of the operator 
for secure communications between the two devices. 
Because of the internal secrets maintained within each 
device and the certificates, the devices can authenticate 
each other and communicate securely, even over an in- 
secure channel, without needing the devbes to have 
been previously programmed with a secret of the oper- 
ator. The devices can authenticate each other and cre- 
ate a shared secret, all over an insecure channel. 



SECURfTY MODUL£ OSM) 
^126 



SECURE SECTION (SS) 









1 TSSIO 




MCERT 








® 


1 KPVTSS, 
|_ KPBfTSS 




KPBSIGM 





^110 

WANUFACTUFUNG tNmALIZATtON FACOJTY 
(MIF) 




VERlFICA-nON CERTIFICATE 



MANUFACTURING 
DATABASE 



, UANUFACmjRtNQ 
WORKSTATION (MWS) 



m. 4. 



Printed by Jouve, 75001 PARIS CFR) 



EP 1 081 891 A3 




European Patent 



EUROPEAN SEARCH RB>ORT 



EP DO 30 7223 



DOOittBHS CONSDERB) TO BE RELEVANT 



cuksancjmoN or THE 



DE 198 01 241 A (DEUTSCHE TELEKOK Afi) 
15 July 1999 (1999-07-15) 

* the whole docunent ♦ 

UO 99 19846 A (GOKDEN NARY L ;LEE ALSON 
(US); VISA INT SERVICE ASS (US)) 
22 April ,1999 (1999-04-22) 

* page 7, line 27 - page 8, 
« pa^^ 9, line 6 - page 10, 

* page 15, line 1 - line 18 
^ page 16, last paragraph ^ 



10 



H04L9/32 



line 13 ♦ 
line 4 * 



tfO 99 35782 A (CRYPTOGRAPHY RESEARCH IMC) 
15 July 1999 (1999-07-15) 

♦ page 7, line 11 - line 26 ♦ 

♦ page 14, line 23 - page 15, line 19 * 



TECHMCALREL06 
SEARCHED (M^T) 



G07F 
H04L 



The present search rapoft has been (imn up tor daiim 



THE HAGUE 



2 April 2002 



Hoi per, G 



CATEGORY OF CfTED DOCUUCMTS 

X 1 perflcutafly fslMBnl tf tstGefi stons 
Y : perflcutartf ntorant tf oomtlnad wSh anorlhei 
doctvnsrt of 9v s 

A: 
O 

P ' illlCNMMldstB (JoOUfTWrtt 



T : ffuKvy or piVc^te undofyfeiQ the InveiTflon 
E : MsDar putMil dboumonU biA piiUU^jd on, or 

D I documBnt dtod in ep|]ncsQon 



fi :fnon)tNrof ffvstfnopotBnt faurtSy. corraapondlng 



2 



EP 1 081 891 A3 



ANNEX TO THE EUROPEAN SEARCH RB>ORT 

ON EUROPEAN PATBfrAPPUCATtON NO. EP 00 30 7223 



TTite amax Hsts m» patant tamfly members reialSng to fho patent dodi merits cfted In tt»o abov©-monttoaed European search raporl 
Tbo (namban 00 ax GortfBfirisd In 1h» EufOpovi Psitwrt Offlc* B3P ^ 
Ths Eurofmn Patwrt Oflloo b ^ no way bbto tor ttiesa pertcUtars 

02-04-2002 



Pedrat dbcufnont 
ciiKi in Mon^ rspoft 



PubOcfilion 



Patcoi tsmly 
inariboris) 



PublicaUDn 



DE 19801241 A 


15-07-1999 


DE 


19801241 Al 


15-07-1999 






WO 


9935781 A2 


15-07-1999 






EP 


1048141 A2 


02-11-2000 


WO 9919846 A 


22-04-1999 


AU 


1081899 A 


03-05-1999 






CA 


2306139 Al 


22-04-1999 






EP 


1023703 A2 


02-08-2000 






\iO 


9919846 A2 


22-04-1999 


WO 9935782 A 


15-07-1999. 


AU 


2557399 A 


26-07-1999 






CA 


2316227 Al 


15-07-1999 






EP 


1050133 Al 


08-11-2000 






WO 


9935782 Al 


15-07-1999 






US 


6304658 81 


16-10-2001 






US 


2001002486 Al 


31-05-2001 



& For morvcMIs about ttbann0x:saeOfadal Journal off th«EuRV)«OTPata^ Na 12^ 



3 



